筆記搬到正確的資料夾了，Frontmatter 也補齊了——可是 brain health 還是把它算成孤立筆記。搬移完成，不等於織入知識網路。

Day15 把「草稿 → 結構化筆記」的分類、Frontmatter 補齊、搬移流程固定成 /refine-inbox，並用兩次驗證（搬移前 brain scan、搬移後 brain health）確保搬移過程不出錯。但如果照著 Day15 的定義實際跑一次，會發現一件不太對勁的事：筆記確實搬到了 20_Areas 或 30_Resources，Frontmatter 也依 note-metadata-schema 補齊了，可是正文從頭到尾沒有一個 Wikilink 指向任何其他筆記，也沒有其他筆記反向連回它——brain health 一樣會把它算進孤立筆記。搬移這個動作本身，跟「這篇筆記有沒有被織入知識網路」是兩件事。

Day10 建立的全庫索引（internal/vault.BuildIndex）其實早就握有能回答「哪些筆記彼此相關」的資料：Index.Tags 這張 tag → 筆記清單的對照表。只是這張表目前只被 brain health 拿來找孤立筆記與斷鏈，從來沒有人把它反過來用——用「共享 tag」這個既有訊號，主動幫剛搬完的筆記牽線。今天要做的事，就是在 /refine-inbox 裡插入一個新步驟：自動織入雙向連結。

為什麼寫正文 ## Related，不寫 frontmatter related

note-metadata-schema（Day04）本來就定義了一個 related 欄位，語意上正是給「筆記關聯」用的，一開始也考慮過最簡單的做法：自動織入時直接把候選筆記的 Wikilink 塞進 related 陣列。但翻開 internal/vault/index.go 才發現，BuildIndex 建出來的 Outbound/Inbound——也就是 brain health 判定孤立筆記的依據——只解析 BodyAST，也就是正文裡的 Wikilink，完全不會讀 frontmatter 的 related 欄位。

這代表如果自動織入只寫 related 陣列，會產生一個沒辦法被既有機制驗證的隱藏行為：/refine-inbox 緊接著執行的「搬移後 brain health 驗證」，看不出這次自動織入到底有沒有生效，也看不出有沒有意外製造斷鏈。等於新增了一個功能，卻讓既有的把關步驟對它視而不見。所以最後選擇寫入正文的 ## Related H2 區塊——讓新增的連結是貨真價實的正文 Wikilink，Outbound/Inbound 才能解析到它，brain health 的孤立筆記數與斷鏈數才能真正反映這次自動織入的效果。related 陣列維持原樣，不動它。

為什麼是 Agent 讀檔重現，不是新增 CLI 指令

第二個決定：要怎麼找出「哪些既有筆記跟這篇筆記共享 tag」？Index.Tags 是 brain-cli 內部的資料結構，沒有任何子指令把它輸出給外部呼叫者查詢，byTitleOrAlias 也是 package-private。要讓 /refine-inbox 用到這個判斷邏輯，最直接的做法是新增一個「輸出 tag → 筆記清單」的查詢指令。

但這麼做會把 Day16 的範圍從 refine-inbox-workflow 一路擴大到 brain-cli-core，而 README 的能力對照表早就把這次異動定位成純 Agent 工作流層的擴充，brain-cli-core 下一次修改排在 Day18/21。demo repo 目前規模很小，Agent 透過既有的 brain scan 取得全庫清單後，逐篇讀取 Frontmatter 的 tags 自行比對重疊，做的事情跟 Index.indexTags 完全一樣，只是執行者從 Go 程式換成了 Agent 讀檔——邏輯一致，範圍不擴大，效能問題留給筆記量真正變大之後再評估。

實際跑一次：Cobra flag 綁定筆記

用 brain capture 捕捉一篇新筆記，內容是「持續會被查閱、不需要主動維護」的 CLI 開發參考資料，補上 tags: ["golang", "cli"]——這跟既有筆記 Cobra CLI 框架.md（同樣 tags: ["golang", "cli"]）有重疊。跑一次 /refine-inbox：

1. PARA 分類：命中判斷問題 3（被動查閱、不需要主動維護）→ 歸入 30_Resources。
2. Frontmatter 補齊：type: inbox-draft → atomic-note，status: seed → growing，tags/related/aliases 維持原樣。
3. 搬移前 brain scan：確認 30_Resources 存在、無同名檔案衝突。
4. 搬移：檔案移入 vault/30_Resources/。
5. 自動織入雙向連結（新步驟）：讀取全庫非草稿筆記的 tags，找到 Cobra CLI 框架.md 共享 golang/cli 兩個 tag；雙方正文都還沒有指向對方的 Wikilink，於是各自在文末新增 ## Related 區塊，互相補上 [[對方標題]]。
6. 搬移後 brain health：確認結果。

執行前，brain health 回報「2 篇孤立筆記」（PARA 筆記法.md 與這篇尚未搬移的草稿）；自動織入完成後，回報「1 篇孤立筆記、0 筆斷鏈」——只剩 Day15 就留在 00_Inbox、內容仍不足以判斷歸屬的 PARA 筆記法.md，這篇新筆記與 Cobra CLI 框架.md 都不再孤立，也沒有新增任何斷鏈。

接著再捕捉第二篇筆記，只帶 tags: ["cli"]（跟前兩篇部分重疊），跑完 /refine-inbox 後，Cobra CLI 框架.md 的 ## Related 區塊被追加了第二個連結，而不是覆蓋或重複——這驗證了「附加不覆寫」與「已存在的 Wikilink 不重複新增」兩條規則同時成立：對已經連過的那一對筆記重新檢查一次，正文裡的 Wikilink 數量始終維持在 1，不會因為重複執行而疊加。

另外也驗證了兩種邊界情況：一篇 tags 補齊後仍為空陣列的筆記（例如內容命中「有明確截止日期」而歸入 10_Projects，但沒有可歸類的 tag），會直接跳過自動織入，不視為錯誤；一篇 tags 不為空、但找不到任何共享 tag 的既有筆記時，也不會硬織入不相關的連結，只在摘要標示「無共享 tag 的相關筆記」。兩種情況下，這些筆記依然會被 brain health 算進孤立筆記——這是符合預期的結果，自動織入解決的是「有訊號可用卻沒人接住」的孤立，不是每篇筆記都保證有關聯。

銜接後續

今天讓 /refine-inbox 從「搬移完成」延伸成「搬移完成且自動織入雙向連結」，把 Day10 全庫索引裡「共享 tag 代表相關」這個一直只用來抓孤立筆記的判斷邏輯，反過來用在主動幫筆記牽線上——而且全程沒有新增一行 brain-cli 的 Go 程式碼，靠既有的 brain scan 加 Agent 讀檔就完成了。這也再次印證 Stage 3 的核心命題：不是每個能力擴充都需要往 CLI 裡加指令，Agent 工作流本身就能承載相當多的邏輯，只要有既有的驗證機制（這裡是 brain health）能兜底檢查它有沒有做對。

接下來 Day17 會處理另一種筆記類型——adr——設計一個 /new-adr 指令，把技術決策記錄的建立也固定成工作流；Day19 則會把 Stage 3 累積的這些指令（/refine-inbox、/new-adr 等）串起來，跑一次完整的 Stage 3 整合 demo。